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ABSTRACT 

The  ability  to  precisely  emplace  stand-alone  payloads  in  hostile  territory  has  long  been  on  the  wish  list  of  US 
warfighters.  This  type  of  activity  is  one  of  the  main  functions  of  special  operation  forces,  often  conducted  at  great 
danger.  Such  risk  can  be  mitigated  by  transitioning  the  manual  placement  of  payloads  over  to  an  automated  placement 
mechanism  by  the  use  of  the  Automatic  Payload  Deployment  System  (APDS).  Based  on  the  Automatically  Deployed 
Communication  Relays  (ADCR)  system,  which  provides  non-line-of-sight  operation  for  unmanned  ground  vehicles  by 
automatically  dropping  radio  relays  when  needed,  the  APDS  takes  this  concept  a  step  further  and  allows  for  the  delivery 
of  a  mixed  variety  of  payloads.  For  example,  payloads  equipped  with  a  camera  and  gas  sensor  in  addition  to  a  radio 
repeater,  can  be  deployed  in  support  of  rescue  operations  of  trapped  miners.  Battlefield  applications  may  include 
delivering  food,  ammunition,  and  medical  supplies  to  the  warfighter.  Covert  operations  may  require  the  unmanned 
emplacement  of  a  network  of  sensors  for  human-presence  detection,  before  undertaking  the  mission.  The  APDS  is  well 
suited  for  these  tasks.  Demonstrations  have  been  conducted  using  an  iRobot  PackBot  EOD  in  delivering  a  variety  of 
payloads,  for  which  the  performance  and  results  will  be  discussed  in  this  paper. 
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1.  INTRODUCTION 

Unmanned  systems  are  increasingly  used  in  the  battlefield  for  a  variety  of  operations.  Unmanned  aerial  vehicles  have 
been  used  to  carry  out  surveillance  missions  and  occasionally  engage  in  air-to-ground  attacks  when  required.  Unmanned 
ground  vehicles  (UGVs)  have  been  primarily  used  in  neutralizing  improvised  explosive  devices  (IEDs),  but  they  have 
also  been  used  as  look-ahead  and  surveillance  tools.  Active  research  areas  in  mobility,  mapping1,  exploration1,  human- 
robot-interaction,  and  advanced  behaviors  promise  to  further  increase  the  role  of  robots  in  the  battlefield  environment. 
Robotic  patient  transport2  and  load  carrying2,  3  are  other  on-going  research  areas  that  will  likely  transition  into  the 
battlefield  environment  to  assist  the  warfighter. 

An  area  that  has  not  been  as  heavily  researched  is  robotic  payload  delivery  and  placement,  which  is  the  focus  of  this 
paper.  A  stand-alone  system  has  been  developed  at  the  Space  and  Naval  Warfare  Systems  Center  (SSC)  Pacific  that 
enables  UGVs  carrying  the  Automatic  Payload  Deployment  System  (APDS)  to  carry  and  deploy  a  mixed  variety  of 
payloads  to  desired  locations.  This  capability  can  have  far  reaching  consequences.  For  example,  UGVs  can  be  used  to 
run  provisions  into  hostile  environments  to  replenish  food,  ammunition,  and  medical  supplies,  eliminating  the  need  of 
placing  warfighters  into  harm’s  way.  UGVs  can  be  used  in  covert  operations  to  deliver  and  emplace  a  network  of 
sensors  used  for  surveillance  and  detection.  In  fact,  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  funded 
the  Camouflaged  Long  Endurance  Nano  Sensors4  (CLENS)  program  that  has  produced  small  sensor  nodes  for  exactly 
this  purpose,  but  they  must  be  hand  placed,  which  can  be  dangerous.  The  APDS  is  designed  to  alleviate  this  danger. 

Remote  nighttime  surveillance  is  another  area  of  interest.  For  example,  covert  delivery  and  placement  of  an  infrared 
(IR)  illuminator  payload  within  proximity  of  a  structure  of  interest  can  aid  remote  surveillance  teams  equipped  with 
night  vision  goggles  (NVGs).  But  a  robotic  payload  delivery  system  need  not  only  be  used  in  the  battlefield 
environment.  The  site  of  a  mine  collapse  is  another  area  where  the  APDS  can  assist  in  rescue  operations.  For  example, 
delivering  a  payload  equipped  with  a  gas  sensor  can  aid  in  gas  analysis  and  data  gathering  activities  to  help  rescue  teams 
deal  with  unexpected  events. 
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The  APDS  is  fully  capable  of  carrying  and  delivering  a  mixed  variety  of  payloads,  which  is  important  when  the  robotic 
platform  must  be  driven  beyond  line-of-sight  (LOS)  to  deliver  its  payloads.  In  this  case  the  payload  delivery  system  can 
also  be  equipped  with  radio  relays  that  automatically  deploy  to  maintain  the  RF  link  with  the  base  station,  allowing  it  to 
continue  on  its  path  to  deliver  the  payloads. 

Section  2  of  this  paper  will  discuss  the  previous  projects  and  systems  on  which  the  APDS  is  based,  while  section  3  will 
discuss  the  system  in  detail.  Test  results  will  be  reported  in  section  4,  and  section  5  will  provide  a  summary  and  current 
status  of  the  system. 


2.  BACKGROUND 

Two  previous  projects  led  to  the  development  of  the  APDS,  which  will  be  discussed  in  chronological  order  here. 

2.1  AMCR 

Digital  radios  have  overwhelmingly  replaced  older  analog  radio  technologies  due  to  improved  link  quality,  reliability, 
and  increased  immunity  to  noise  and  multipath  fading.  Digital  radios,  however,  usually  operate  at  much  higher 
frequencies,  requiring  that  a  RF  LOS  be  maintained  between  the  robot  and  its  operator.  This  can  severely  limit  the  use 
of  tactical  robots,  especially  in  urban  environments. 

A  solution  to  the  LOS  issue  was  formulated  under  the  DARPA-funded  Autonomous  Mobile  Communication  Relays5 
(AMCR)  project  (2002  -  2004),  where  radio  relays  were  used  to  maintain  the  link  with  the  control  station  as  the  tactical 
robot  is  driven  beyond  LOS.  The  radio  relays  were  carried  by  small  mobile  robots,  turning  them  into  mobile  relay  nodes 
that  followed  the  lead  tactical  robot  in  convoy  fashion  along  its  exploratory  path.  When  the  last  mobile  node  in  the 
convoy  detected  that  the  link  to  the  base  station  was  about  to  break  it  stopped  and  became  a  stationary  relay  as  the 
remainder  of  the  convoy  continued.  This  process  was  repeated  until  all  mobile  relay  nodes  had  stopped. 

The  heart  of  the  AMCR  system  was  the  relay  radio6  carried  by  each  robot.  The  network  software  onboard  the  relay 
radio,  developed  by  BBN  Technologies  under  a  separate  DARPA-funded  effort,  used  the  proactive  Hazy  Sighted  Link 
State7  (HSLS)  routing  protocol  and  a  predictive  filter.  The  output  of  this  predictive  filter  was  compared  to  a 
predetermined  threshold,  below  which  a  mobile  node  would  stop  to  maintain  the  link. 

2.2  ADCR 

As  successful  as  the  AMCR  project  was  at  maintain  the  RF  communications  link,  it  was  not  a  practical  system. 
Providing  a  tactical  robot  with  non-line-of-sight  (NLOS)  operational  capability  will  be  expensive  and  come  at  a  high 
logistical  cost  under  the  AMCR  approach,  due  to  the  fact  that  the  mobile  node  will  be  much  more  expensive  than  the  RF 
relay  it  carries.  Additionally,  each  mobile  node  must  carry  sensors  to  provide  autonomous  navigational  capability 
required  to  follow  the  lead  robot  wherever  it  explores,  increasing  system  cost.  Logistically,  transporting  and  setting  up 
the  convoy  before  undertaking  a  mission  is  completely  unrealistic. 

Therefore,  a  more  practical  and  cost-effective  solution  was  developed  under  the  Automatically  Deployed 
Communication  Relays8  (ADCR)  project  (2004  -  2008),  funded  by  the  Joint  Ground  Robotics  Enterprise  (JGRE).  The 
relay  radio  previously  developed  under  the  AMCR  project  was  transitioned  over  to  the  ADCR  project  and  integrated  into 
the  ADCR  system. 

The  ADCR  system  consists  of  two  devices;  the  Deploy er  and  the  Relay  Brick,  shown  in  Figure  1.  Up  to  six  Relay 
Bricks  are  carried  by  the  Deploy  er,  which  in  turn  is  carried  by  the  UGV  (e.g.  iRobot  PackBot  EOD  shown  in  Figure  1) 
that  requires  NLOS  operational  capability.  The  UGV  interfaces  with  the  Deploy  er  via  an  Ethernet  connection.  The 
Deployer  and  the  Relay  Bricks  each  contain  an  AMCR  radio  and  are  self  powered. 

Unlike  the  AMCR  system,  where  each  mobile  node  monitors  the  previous  one-hop  neighbor,  under  the  ADCR  system 
only  the  Deployer  monitors  the  network.  As  the  UGV  moves  away  from  the  base  station  and  the  Deployer  senses  that 
the  link  is  about  to  break  it  will  automatically  trigger  the  release  of  a  Relay  Brick.  This  process  is  identical  to  that  used 
under  the  AMCR  system  to  trigger  the  halting  of  a  mobile  node.  The  Deployer  uses  the  same  predictive  filter  along  with 
a  predetermined  threshold  setting  to  trigger  the  release  of  a  Relay  Brick.  Once  released,  the  Relay  Brick  self  rights, 
extends  its  antenna,  and  becomes  a  static  relay  radio.  This  process  is  transparent  to  the  operator  and  repeats  itself 
automatically  until  all  Relay  Bricks  have  been  spent. 


Figure  1.  Left  image  shows  the  ADCR  Deployer  and  Relay  Brick.  Right  image  shows  the  iRobot  PackBot  EOD  carrying  the 
Deployer  containing  five  stowed  Relay  Bricks  and  one  deployed  with  extended  antenna. 

In  2007,  a  test  of  the  ADCR  system  was  conducted  along  a  NLOS  path  with  various  curvatures,  hills  and  dips,  for  which 
the  test  results  shown  in  Figure  2  depict  the  deployed  locations  of  the  Relay  Bricks.  The  test  was  conducted  under 
threshold  levels  of  40  and  45  indicated  by  the  red  discs  and  blue  boxes,  respectively  (see  reference  8  for  more  details). 
The  threshold  level  represents  the  amount  of  power  above  the  minimum  required  by  the  receiver  to  communicate  at 
1Mbps.  For  example,  if  the  minimum  power  level  is  -94dBm  and  the  threshold  level  is  45,  than  a  Relay  Brick  will  be 
deployed  if  the  received  power  level  of  the  Deployer  falls  below  -49dBm.  Generally  speaking,  lower  threshold  levels 
increase  the  distance  between  deployed  Relay  Bricks,  but  this  is  highly  terrain  and  multipath  dependent.  Because  the 
Relay  Bricks  did  not  support  diversity  antennas  that  can  alleviate  the  effects  of  multipath,  the  system  was  especially 
vulnerable  to  premature  deployment  of  Relay  Bricks  when  relatively  large  local  nulls  were  present. 


Figure  2.  Travel  path  with  threshold  set  to  45  (blue  box  and  line),  threshold  set  to  40  (red  disc  and  line),  and  PackBot  without  the 
ADCR  system  (orange  line).  Black  triangle  shows  final  location  of  the  PackBot  when  the  link  with  the  base  station  is  lost. 

Various  conference  publications  and  successful  demonstrations  of  the  ADCR  system  generated  a  great  deal  of  interest 
from  the  Naval  EOD  Technology  Division  (NAVEODTECHDIV)  for  use  in  providing  extended  range  for  EOD  robots 
in  defeating  IEDs.  Significant  interest  also  arose  from  the  Environmental  Protection  Agency  (EPA)  and  the  Mine  Safety 
and  Health  Administration  (MSHA).  The  EPA  requires  extended  range  and  NLOS  operation  for  their  UGVs  used  to 
investigate  hazardous  spills.  MSHA  is  interested  in  using  robots  to  investigate  mine  collapses,  requiring  the  robot  to 
travel  beyond  LOS.  Even  NASA  showed  interest  in  investigating  the  use  of  the  ADCR  system  for  setting  up  a 
temporary  network  on  the  lunar  surface.  This  degree  of  interest  resulted  in  the  signing  of  licensing  agreements  by  three 
commercial  entities  for  production  and  sale  of  the  ADCR  system. 

As  successful  as  the  ADCR  system  is,  it  is  not  without  its  drawbacks.  The  roundtrip  delay  between  the  operator  and  the 
robot  grows  to  impractical  levels  with  the  increasing  number  of  deployed  Relay  Bricks.  It  is  not  uncommon  to 


experience  several  seconds  of  delay  measured  from  the  time  the  robot  is  commanded  to  move  forward  until  the  change 
in  the  video  is  seen  by  the  operator.  This  is  unacceptable  if  the  robot  is  to  be  used  in  IED  defeat  missions.  The  cause  of 
the  delay  comes  from  the  802.11b  radios  being  overwhelmed  by  the  high- frame-rate  video  streams  generated  by  the 
PackBot.  Dropping  the  frame  rate  by  half  significantly  reduces  the  roundtrip  delay,  but  it  is  still  above  acceptable  limits. 

As  discussed  earlier  the  single  antenna  approach  is  more  prone  to  multipath  effects.  The  self-righting  and  antenna-lift 
mechanisms  are  mechanically  complex  and  not  well  suited  for  use  in  a  sandy  environment,  which  sometimes  prevents  a 
Relay  Brick  from  self-righting.  The  antenna  mast  height  needed  to  be  lowered  to  reduce  weight  and  ensure  proper 
extension,  but  low  antenna  height  is  undesirable  as  it  reduces  the  Fresnel  Zone  clearance. 

Because  the  ADCR  system  was  designed  specifically  to  provide  extended  range  and  NLOS  operational  capability,  it 
lacks  the  flexibility  to  deploy  non-Relay  Brick  payloads.  This  was  evident  in  2007  when  a  collaborative  effort  took 
place  between  SSC  Pacific  and  CornerTum  LLC  in  an  attempt  to  deploy  the  BOTDROPS9  leave-behind  surveillance 
sensors  from  the  Deployer.  Though  successful,  the  lack  of  flexibility  of  the  system  rendered  this  effort  non-trivial.  The 
need  for  this  capability  became  clear  in  2008  based  on  feedback  from  Marines  at  Camp  Pendleton,  where  the  desire  to 
deploy  various  other  types  of  payloads  was  discussed.  With  all  this  in  mind,  a  next-generation  version  of  the  system  was 
designed  from  the  ground  up  to  address  the  drawbacks,  improve  upon  the  system,  and  provide  a  capability  to  deploy 
various  types  of  payloads. 


3.  APDS 

The  design  approach  taken  in  the  development  of  the  Automatic  Payload  Deployment  System  (APDS)  was  to 
incorporate  what  worked  well  in  the  ADCR  system  and  improve  upon  its  limitations  based  on  lessons  learned,  while 
providing  built-in  flexibility  to  allow  support  for  various  payload  types.  The  work  began  by  redefining  the  architecture 
to  be  inherently  more  generic  and  flexible.  Then,  a  new  APDS  Deployer  was  designed  along  with  a  new  Next 
Generation  (NG)  Relay  Brick,  but  this  time  the  Relay  Brick  represents  only  one  of  many  different  types  of  payloads 
supported  by  the  APDS  Deployer. 

3.1  APDS  architecture 

The  purpose  of  the  ADCR  system  was  quite  specific:  to  deploy  Relay  Bricks.  The  system  architecture  was  therefore 
limited  and  not  flexible  enough  to  handle  other  types  of  payloads.  In  contrast  the  APDS  architecture  is  designed  to 
rectify  such  limitations.  Similar  to  the  ADCR  system,  the  APDS  replaces  the  native  wireless  communications  system  of 
the  UGV  with  the  mesh  network  formed  by  the  Deployer  radio,  Relay  Bricks,  and  Base  Station  Unit  (BSU)  radio,  shown 
in  Figure  3.  It  is  important  to  note  that  the  native  radios  are  not  physically  removed  from  the  UGV  and  its  controller,  but 
merely  deactivated  (usually  via  software  commands)  to  eliminate  interference  with  the  APDS  radios.  Should  the  Relay 
Bricks  not  be  used,  the  wireless  link  formed  by  the  Deployer  radio  and  the  BSU  radio  will  be  equivalent  to  the  point-to- 
point  topology  of  the  native  system. 

The  APDS  architecture  is  designed  with  built-in  flexibility  to  allow  for  the  deployment  of  not  only  Relay  Bricks  but  also 
other  types  of  payloads  by  incorporating  the  following: 

•  Infrared  Data  Association  (IrDA)  transceivers  -  All  payloads  are  required  to  have  an  IrDA  transceiver  to  properly 
communicate  with  the  Deployer  when  stowed. 

•  APDS  communications  protocol  -  This  protocol  defines  a  standard  messaging  system  used  to  communicate  with  the 
APDS  Deployer  and  its  payloads. 

•  Support  for  deploying  double- wide  and  triple- wide  payloads  -  The  APDS  Deployer  is  able  to  accept  payloads  that 
are  2  or  3  times  the  width  of  a  standard  single-wide  payload,  providing  more  volume  as  required. 

The  integration  of  IrDA  transceivers  is  a  key  feature  of  the  APDS  architecture.  This  allows  complex  information  to  be 
exchanged  between  the  APDS  Deployer  and  the  stowed  payloads.  The  NG  Relay  Bricks,  for  example,  are  “blank” 
radios  that  require  the  proper  network  parameters  to  fully  boot.  Instead  of  preprogramming  an  NG  Relay  Brick  with 
fixed  values,  the  Deployer  simply  provides  them  via  the  IrDA  interface  when  the  NG  Relay  Brick  is  stowed.  Similarly, 
a  payload  reports  its  size  (e.g.  single-wide,  double-wide,  or  triple-wide)  to  the  Deployer  via  the  IrDA  interface  so  that  the 
correct  servo-motors  are  actuated  for  payload  release. 


Figure  3  shows  the  communications  connections  between  various  devices.  The  messages  exchanged  between  these 
devices  through  the  channels  shown  use  the  APDS  communications  protocol.  The  Ethernet  and  802.11  protocols  are 
unchanged  and  simply  transport  the  APDS  packets  in  their  data  frame. 

Support  for  various  sized  payloads  adds  a  great  deal  of  flexibility  in  the  types  of  payloads  that  can  be  deployed.  For 
example,  some  supplies  such  as  food  and  ammunition  will  not  fit  within  a  single-wide  payload,  but  will  fit  within  a 
double-wide  or  triple-wide  payload. 
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Figure  3.  Illustration  of  the  APDS  replacing  the  native  wireless  system  of  the  UGV.  Data  is  relayed  between  the  UGV  and  its 
controller  via  two  deployed  NG  Relay  Bricks.  The  APDS  Deployer  still  carries  one  NG  Relay  Brick  and  one  other  payload  type. 

The  purpose  of  the  BSU  (Figure  4)  developed  for  the  APDS  is  to  provide  a  user  interface  that  displays  system  status 
information,  allows  devices  on  the  network  to  be  remotely  accessed  for  specific  functions,  and  provides  a  manual  deploy 
command  for  each  payload. 


G 


Diversity  antenna  connection 

Figure  4.  BSU  showing  tablet  PC  on  top  and  radio  enclosure  mounted  on  the  bottom. 

Certain  information,  such  as  remaining  battery  capacity  and  link  connectivity  (for  NG  Relay  Bricks),  is  automatically 
forwarded  to  the  BSU.  If  the  Deployer  only  carries  Relay  Bricks  and  such  information  is  deemed  non-critical,  the  BSU 
need  not  be  used.  The  Deployer  will  automatically  and  without  operator  intervention  deploy  the  Relay  Bricks  when  and 
where  needed  to  maintain  the  link.  If  the  BSU  is  not  used,  the  UGV  controller  must  be  interfaced  to  a  radio  identical  to 
what  resides  in  a  Deployer  and  Relay  Brick  for  proper  functionality  of  the  network. 

If  other  types  of  payloads  are  used,  such  as  those  discussed  in  sections  3.5  and  3.6,  then  the  BSU  is  required,  in  order  to 
allow  the  operator  to  manually  command  the  release  of  these  payloads  at  the  desired  locations.  Once  deployed,  the 
payloads  can  also  be  remotely  accessed  via  the  BSU. 


The  BSU  hardware  consists  of  a  tablet  PC  interfaced  to  a  mesh  network  radio,  an  Ethernet  switch,  a  battery  pack,  and 
power  regulation  circuitry.  Since  UGVs  usually  have  a  dedicated  control  unit,  the  addition  of  the  BSU  will  add  to  the 
required  hardware  at  the  base  station.  Development  efforts,  such  as  the  Multi-robot  Operator  Control  Unit10  (MOCU), 
are  underway  to  design  a  software-based  common  controller  for  unmanned  systems.  Installing  MOCU  on  the  BSU 
tablet  PC  will  eliminate  the  need  for  the  UGV  controllers,  which  typically  are  much  larger  and  heavier  than  the  BSU. 

3.2  APDS  Deployer 

Similar  to  the  ADCR  Deployer,  the  APDS  Deployer  consists  of  six  chambers  and  an  internal  power  source.  They  differ 
in  that  the  chambers  of  the  APDS  Deployer  are  arranged  in  a  2x3  array  as  opposed  to  the  3x2  array  of  the  ADCR 
Deployer.  Additionally,  the  APDS  Deployer  can  be  externally  powered  while  its  battery  pack  is  charging;  a  feature  not 
available  in  the  ADCR  Deployer. 

The  APDS  Deployer  is  volumetrically  smaller  than  the  ADCR  Deployer  by  about  21%,  and  half  its  width,  which  allows 
it  to  occupy  only  one  of  the  three  payload  bays  of  the  iRobot  PackBot.  Unlike  the  ADCR  Deployer,  where  a  linear 
latching  and  launching  mechanism  are  used,  the  APDS  Deployer  uses  rotational  mechanics,  which  is  much  less 
susceptible  to  jamming,  thus  improving  system  reliability.  The  constant- force  rotational  spring  found  in  each  chamber 
of  the  APDS  Deployer  has  the  added  benefit  of  easing  the  loading  of  payloads.  It  is  no  longer  necessary  to  push  with 
increasing  force  to  load  a  Relay  Brick  into  the  Deployer.  When  loaded,  a  rotational  latch  holds  the  payload  in  place  until 
actuated  by  a  servo-motor  when  the  payload  is  released. 

A  significant  addition  to  the  APDS  Deployer  that  is  not  found  in  the  ADCR  Deployer  is  an  IrDA  transceiver  located  at 
the  end  of  each  chamber.  The  IrDA  transceiver  provides  bidirectional  communications  at  a  maximum  rate  of  115.2 
Kbps  between  the  Deployer  and  a  payload. 

The  APDS  Deployer  contains  a  dedicated  microcontroller  (jaC)  board  that  includes  all  the  circuitry  needed  to  control  the 
servo-motors,  communicate  with  the  radio  through  a  RS-232  interface,  manage  communications  with  the  payloads  via 
the  IrDA  interface,  charge  the  onboard  Lithium-ion  battery  pack,  and  provide  battery  capacity  via  a  fuel  gauge  chip. 


Top  row 
Bottom  row 


Figure  5.  Each  row  of  the  APDS  Deployer  can  support  a  single-wide,  double-wide,  or  triple-wide  payload. 

3.3  Next  Generation  Relay  Brick 

The  NG  Relay  Brick,  shown  in  Figure  3,  is  a  few  inches  longer  than  the  ADCR  Relay  Brick,  but  it  is  about  one-third  its 
height  and  volumetrically  less  by  about  26%.  Another  significant  mechanical  difference  is  in  the  self-righting  and 
antenna-lift  mechanism.  As  discussed  earlier,  the  self-righting  mechanism  of  the  ADCR  Relay  Brick  can  sometimes  fail 
on  sand.  Another  issue  is  the  wear  and  tear  of  the  RF  cable  running  along  the  mast  as  its  spring-loaded  linkages  (see 
Figure  1)  are  folded  and  stowed  in  the  antenna  compartment  for  reuse.  Additionally,  under  certain  gusty  conditions  the 


base  spring  may  not  be  strong  enough  to  prevent  wild  flapping  of  the  mast,  which  may  cause  link  disruption.  This 
problem  is  further  magnified  on  a  slope  where  the  base  spring  must  also  fight  against  gravity. 

The  new  design  eliminates  these  issues.  The  NG  Relay  Brick  is  geometrically  constrained  to  land  face  up  or  face  down 
and  not  on  the  thin  edges.  Once  deployed,  it  uses  its  onboard  accelerometer  to  determine  when  it  has  come  to  rest,  then 
rotates  the  antennas  up  until  parallel  to  the  gravity  vector,  regardless  of  the  slope  upon  which  it  lands.  (Note  that  the 
antennas  will  be  parallel  to  the  gravity  vector  only  along  a  single  axis  if  the  NG  Relay  Brick  is  pitched  around  the  axis 
that  runs  along  the  length  of  its  body.  Furthermore,  the  pitch  angle  must  be  within  a  certain  limit  before  antennas  are 
raised.)  The  servo-motor  rotating  the  masts  continuously  reacts  to  external  forces,  such  as  a  gust  of  wind,  to  keep  the 
masts  in  the  desired  orientation.  The  RF  cable  running  through  the  mast  and  the  rotating  shaft  at  the  base  is  prevented 
from  wear  and  tear  as  it  is  only  twisted  by  a  small  amount,  even  when  the  antennas  are  rotated  to  the  maximum  limits. 

The  NG  Relay  Brick  supports  a  custom  jaC  board  that  is  used  to  interface  to  the  radio  via  an  RS-232  connection, 
interface  to  an  IrDA  transceiver  as  required  by  the  APDS  architecture,  and  control  a  servo-motor  to  rotate  the  antenna 
masts  based  on  the  onboard  accelerometer  data.  An  internal  Lithium-ion  charging  circuit  is  also  included  that  only 
requires  a  low  cost  external  voltage  source  to  charge  the  battery  pack.  Additional  power  and  serial  ports  are  available  to 
interface  to  other  circuit  boards  for  increased  functionality.  For  instance,  sensors  can  be  placed  between  the  antenna 
masts  as  an  added  benefit  and  powered  from  these  ports,  examples  of  which  will  be  discussed  in  sections  3.5  and  3.6. 
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Figure  6.  Next  Generation  Relay  Brick  with  raised  antennas  that  are  24”  above  ground. 

3.4  Mesh  network  radio 

The  APDS  Deployer  and  NG  Relay  Bricks  have  been  upgraded  with  a  high-data-rate  802. 1  lg  radio.  As  evident  from  the 
dual  antenna  masts  shown  in  Figures  5  and  6,  diversity  antennas  are  supported,  which  help  lessen  the  effects  of  multipath 
interference.  The  radio  hardware  is  composed  of  a  single-board-computer  interfaced  to  a  miniPCI  802.1  lg  radio  via  an 
interconnect  board  developed  by  Raj  ant  Corp. 

BBN  Technologies  has  ported  the  network  software  developed  under  AMCR  to  the  new  radio  hardware.  The  aspect  of 
the  code  that  runs  the  mesh  network  is  proprietary  and  cannot  be  modified;  however,  the  portion  of  the  code  that  deals 
with  the  radio  boot  sequence,  network  monitor,  relay  release  trigger,  and  microcontroller  communications  can  be 
modified.  The  in-house  modifications  of  these  portions  of  the  code,  listed  below,  have  greatly  enhanced  the 
performance  of  the  network  and  deployment  system: 

•  Rapid  availability  of  a  relay  for  deployment  -  When  the  APDS  Deployer  is  first  activated,  all  available  NG  Relay 
Bricks  are  powered  on  and  fully  booted.  The  transmitters  of  all  but  one  of  the  Relay  Bricks  are  deactivated  however, 
to  prevent  overdriving  of  receivers  due  to  close  proximity  of  all  the  radios.  When  a  Relay  Brick  is  deployed,  the 
next  Relay  Brick  in  the  Deployer  becomes  available  for  deployment  in  approximately  3  seconds.  This  is  an 


improvement  of  over  an  order  of  magnitude  as  compared  to  the  ADCR  system  in  which  the  Relay  Bricks  took  about 
40  seconds  to  boot  up.  This  type  of  delay  is  unacceptable  when  operating  in  complex  urban  environments  where  the 
robot  may  be  required  to  deploy  multiple  relays  in  rapid  succession. 

•  Implementation  of  a  moving  average  (MA)  filter  -  The  output  of  the  BBN  predictive  filter  is  compared  to  a  preset 
threshold,  below  which  the  release  of  a  Relay  Brick  is  triggered.  Sharp  variations  or  spikes  due  to  local  RF  nulls 
can  cause  the  output  data  to  drop  below  the  threshold,  prematurely  releasing  a  Relay  Brick.  The  MA  filter 
eliminates  this  problem  and  results  in  more  consistent  performance  in  the  deployed  locations  of  NG  Relay  Bricks 
when  the  results  of  several  test  trials  are  compared. 

•  Deployer  payload  monitoring  -  The  Deployer  is  constantly  monitoring  its  chambers  to  detect  the  insertion  and 
removal  of  payloads  and  their  current  status.  This  is  used  for  verification  that  a  payload  is  functioning  and  ready  for 
deployment. 

•  Payload  fault  detection  -  The  Deployer  monitors  for  faults  in  the  startup  status  of  Relay  Bricks  and  attempts  to 
correct  any  issues  that  arise.  The  goal  is  to  always  have  one  Relay  Brick  ready  for  deployment  at  all  times.  If  a 
Relay  Brick  fails  at  any  stage  of  the  startup  process  the  Deployer  chooses  a  new  Relay  Brick  for  deployment  and 
attempts  to  reset  the  offending  relay. 

3.5  Camera  Node 

The  Camera  Node  is  a  new  payload  type  that  was  developed  to  demonstrate  the  flexibility  of  the  APDS  Deployer  and 
payload  designs.  It  is  essentially  a  double-wide  Relay  Brick  with  a  camera  and  supporting  electronics  used  to  transmit 
the  video  over  the  wireless  link  to  the  BSU.  The  height  of  an  existing  NG  Relay  Brick  was  doubled  to  provide  extra 
volume  needed  to  contain  a  commercial-off-the-shelf  video  server,  voltage  regulators,  and  an  in-house  developed 
Ethernet  switch.  An  automotive- grade  Sony  camera  with  a  field-of-view  of  greater  than  180°  vertical  and  360° 
horizontal  was  mounted  between  the  antenna  masts  (see  Figure  7).  Power  is  provided  to  the  camera  and  supporting 
electronics  via  the  extra  power  ports  of  the  NG  Relay  Brick  jaC  board. 


Figure  7.  Camera  Node  showing  Sony  camera  mounted  between  the  antenna  masts,  pointing  up. 

Because  the  camera  node  contains  a  relay  radio,  the  Deployer  can  automatically  deploy  it  as  if  it  is  a  NG  Relay  Brick. 
On  the  other  hand,  since  the  camera  node  reports  its  type  and  size  to  the  Deployer,  the  Deployer  can  be  programmed  to 
ignore  the  camera  node  as  a  possible  candidate  for  a  relay,  allowing  the  operator  to  release  the  camera  node  at  a  strategic 
location  through  a  manual  deploy  command  sent  from  the  BSU.  The  video  stream  displayed  on  the  BSU  can  be  initiated 
in  several  ways;  1)  from  the  initial  power  up  sequence  while  it  is  stowed  in  the  Deployer,  providing  a  rear- view 
perspective  from  the  UGV,  2)  after  the  brick  has  been  deployed  and  the  antennas  have  been  raised,  3)  remotely  triggered 
by  the  operator  via  the  BSU,  and  4)  triggered  based  on  vibration  sensed  by  the  accelerometer. 

3.6  Infrared  Illuminator  Node 

The  near-infrared  (IR)  Illuminator  Node,  another  payload  type  based  on  the  NG  Relay  Brick,  is  a  single-wide  payload 
that  supports  an  IR  LED  package  mounted  between  the  antenna  masts  (see  Figure  8).  The  package  contains  an  array  of 


five  high-power  wide-field-of-view  LEDs  on  each  side.  Although  each  array  can  be  independently  activated  as  required, 
activating  both  arrays  can  provide  a  fairly  uniform  illumination  of  the  surrounding  area.  With  both  sides  active,  a  total 
of  approximately  10W  is  consumed,  providing  a  radiant  flux  of  about  3W.  The  LEDs  can  be  activated  automatically 
after  deployment  or  remotely  at  a  later  time  by  the  operator  via  the  BSU.  The  node  allows  covert  remote  night-time 
observation  of  critical  locations  or  high-value  targets. 

Figure  8.  Illuminator  node  showing  IR  LED  package  housing  an  array  of  five  LED  clusters  on  both  sides. 

4.  TEST  RESULTS 


4.1  Outdoor  NLOS  Test 

This  test  was  conducted  using  an  iRobot  PackBot  EOD  carrying  the  APDS  Deployer  (Figure  9)  along  the  same  NLOS 
path  used  in  the  ADCR  testing  (see  Figure  2).  The  objective  of  this  test  was  to  drive  the  PackBot  continuously  along  this 
road  until  beyond  the  range  of  the  last  deployed  relay,  then  measure  the  distance  and  obtain  a  subjective  measure  of 
performance  from  the  operator’s  point  of  view  in  terms  of  link  reliability  and  latency.  The  range  and  performance  was 
then  compared  to  the  ADCR  system. 


Figure  9.  EOD  PackBot  carrying  the  APDS  Deployer  containing  three  stowed  NG  Relay  Bricks  and  one  deployed  with  raised 

antennas. 

As  a  purely  subjective  measurement,  link  reliability  is  defined  as  the  tendency  for  the  link  between  the  BSU  and  the 
robot  to  remain  connected  as  perceived  by  the  operator.  The  latency  is  defined  as  the  operator’s  perceived  delay  from 


the  time  a  command  is  issued  until  the  corresponding  response  is  seen  on  the  video  feedback.  As  an  example,  under  the 
ADCR  system,  link  reliability  began  to  decline  and  latency  began  to  grow  with  increased  number  of  deployed  Relay 
Bricks.  A  latency  of  several  seconds  was  observed  with  all  six  Relay  Bricks  deployed.  Cutting  the  frame  rate  of  the  two 
video  streams  of  the  PackBot  by  half  (to  15fps)  improved  link  reliability  but  the  roundtrip  latency  did  not  drop  below 
about  1  second,  which  is  an  unacceptable  delay.  With  these  settings  the  PackBot  travelled  approximately  540m. 

With  the  upgraded  radios  the  PackBot  travelled  about  550m.  Even  though  the  travel  distance  is  roughly  the  same  as 
compared  to  the  ADCR  test,  the  link  reliability  and  latency  have  been  significantly  improved.  The  roundtrip  latency,  for 
example,  is  unnoticeable  even  when  the  video  streams  are  set  to  30fps  and  six  NG  Relay  Bricks  are  deployed.  A 
significant  improvement  in  link  reliability  allowed  the  operator  to  continuously  drive  the  PackBot  from  the  starting 
position  until  the  final  locations,  under  both  the  “normal”  and  “fast”  speed  modes  set  by  the  PackBot  controller.  The 
deployed  locations  of  the  NG  Relay  Bricks  (with  a  threshold  setting  of  45)  for  both  speed  modes  are  shown  in  Figure  10. 


Figure  10.  Travel  path  of  PackBot  showing  deployed  locations  of  NG  Relay  Bricks  (RBI  to  RB6)  and  final  position  of  PackBot 
(triangle)  with  a  threshold  setting  of  45.  Blue  disks  and  red  boxes  indicate  deployed  locations  under  “normal”  and  “fast”  speed 

modes,  respectively. 


4.2  Mixed  Indoor/Outdoor  NLOS  Test 

The  system  was  tested  in  a  WWII  bunker  constructed  of  12-foot  thick  steel-reinforced  walls  that  highly  attenuate  radio 
signals.  The  BSU  was  set  up  outside  the  structure  and  the  operator  continuously  controlled  the  PackBot  as  it  was  driven 
through  the  bunker  and  around  the  large  hill,  completing  the  loop.  The  deployed  locations  of  the  NG  Relay  Bricks  are 
shown  in  Figure  1 1 .  More  NG  Relay  Bricks  are  deployed  inside  the  structure  due  to  the  severe  NFOS  nature  of  the  path. 


Figure  11.  Travel  path  of  the  PackBot  carrying  the  APDS  system  showing  deployed  locations  of  the  NG  Relay  Bricks  through  the 
WWII  bunker  and  around  the  hill,  with  threshold  level  set  to  45.  Black  triangle  at  top  center  shows  the  final  location  of  the  PackBot. 


4.3  Camera  Node  Test 

The  capability  of  deploying  a  mixed  variety  of  payloads  was  tested  by  loading  the  APDS  Deploy er  with  four  NG  Relay 
Bricks  and  one  Camera  Node  (shown  in  Figure  7).  The  Camera  Node  is  a  double-wide  payload  taking  up  two  of  the 
three  available  chambers  on  the  bottom  row.  This  allowed  the  APDS  Deployer  to  be  loaded  with  four  single-wide  NG 
Relay  Bricks;  three  on  the  top  row  and  one  on  the  bottom. 

The  system  was  tested  along  the  same  NLOS  path  discussed  in  section  4.1.  As  the  PackBot  was  driven  along  this  path, 
the  NG  Relay  Bricks  were  automatically  deployed  at  locations  that  are  in  very  close  proximity  to  the  locations  of  RBI  to 
RB4.  At  the  approximate  location  of  RB5  the  operator  commanded  the  release  of  the  Camera  Node  from  the  BSU.  The 
node  deployed,  its  antennas  rose,  and  video  began  streaming  to  the  BSU  through  the  network.  At  this  point  the  network 
was  handling  three  video  streams;  two  streams  from  the  PackBot  and  one  from  the  Camera  Node.  The  PackBot  was  still 
under  the  control  of  the  operator,  although  there  was  a  slight  increase  in  latency  due  to  the  increase  in  data  traffic. 

Figure  12  shows  sample  images  from  a  captured  video  sequence  received  from  the  Camera  Node.  The  left  image  shows 
a  rear  view  when  the  Camera  Node  is  stowed  on  the  PackBot.  A  newly  deployed  NG  Relay  Brick  can  be  seen.  The 
right  image  shows  the  view  from  the  Camera  Node  when  it  has  been  deployed  and  its  antennas  raised.  Even  though  the 
camera  is  pointing  up,  its  wide  field-of-view  allows  objects  lower  than  the  height  of  the  camera  to  be  seen,  such  as  the 
PackBot  as  it  drives  away. 


Figure  12.  Screenshots  of  the  video  received  from  the  Camera  Node  when  stowed  (left  image)  and  when  deployed  (right  image). 


4.4  Illuminator  Node  Test 


To  examine  the  effectiveness  of  the  Illuminator  Node  in  a  dark  environment,  a  test  was  conducted  inside  the  WWII 
bunker  with  all  the  doors  shut  and  the  interior  lights  turned  off.  With  the  aid  of  the  onboard  headlights,  the  operator 
situated  outside  the  structure  drove  the  PackBot  inside  and  into  a  designated  room.  Here  the  progress  of  the  PackBot 
was  tracked  by  an  individual  with  the  aid  of  a  pair  of  Gen-III  AN/PVS-7C  NVGs.  Once  inside  the  room,  the  operator 
commanded  the  release  of  the  Illuminator  Node.  The  operator  then  drove  the  PackBot  out  of  the  room  to  eliminate  any 
source  of  light  (e.g.,  visible  LEDs  on  PackBot  and  Deployer)  from  contributing  to  the  light  of  the  Illuminator  Node,  with 
result  is  shown  in  Figure  13.  The  photos  come  from  individual  frames  from  a  video  camera  looking  through  the  NVGs. 


View  with  NVCaCafrer  IR  Node  \$ 
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Dark  room  viewed  with  Gen  III  NVG 
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Figure  13.  Before  (left  image)  and  after  (center  and  right)  images  of  the  illuminated  room.  Center  image  shows  direct  view  of 
Illuminator  Node.  Right  image  shows  a  better  representation  when  not  directly  viewing  the  IR  LED  source. 


This  test  demonstrated  the  significant  difference  in  illumination  when  looking  through  the  Gen-III  NVGs,  which  are 
currently  fielded  units.  Without  the  Illuminator  node  the  NVGs  essentially  see  nothing  as  shown  in  the  left  image  of 
Figure  13,  whereas  with  the  node  the  room  is  effectively  illuminated.  When  looking  directly  at  the  source  of  light,  the 


iris  of  the  video  camera  auto-adjusts  and  therefore  the  background  looks  darker  than  it  appears  when  looking  through  the 
NVGs.  The  left  image  is  a  better  representation  of  what  is  seen  through  the  NVGs  when  looking  away  from  the  source 
of  light. 


5.  CONCLUSION 

The  evolutionary  path  of  the  APDS  began  from  the  AMCR  project  where  the  operational  range  of  a  lead  robot  was 
increased  via  mobile  relay  nodes  following  in  convoy  fashion.  These  mobile  relay  nodes  stopped  automatically  to 
maintain  the  link  with  the  base  station.  Although  the  project  was  successful,  it  was  impractical  for  use  in  the  field. 
Hence,  the  AMCR  system  evolved  into  the  more  practical  ADCR  system,  where  the  mobile  relay  nodes  were  replaced 
with  the  static  Relay  Bricks  carried  by  the  tactical  robot  and  deployed  when  needed  to  maintain  the  link.  The  concept  of 
deploying  Relay  Bricks  naturally  led  to  deploying  other  types  of  payloads  from  a  robotic  platform.  The  need  for  this 
idea  was  reinforced  by  Marines  at  Camp  Pendleton,  who  provided  ideas  on  various  other  payload  types  as  well  as  the 
demonstration  conducted  to  deploy  the  BOTDROPS  from  the  ADCR  Deployer. 

The  development  of  a  new  Deployer  began  under  the  APDS  project  to  provide  a  robotic  platform  the  capability  of 
carrying  and  deploying  various  types  of  payloads.  To  demonstrate  this  capability  three  different  payloads  were 
developed;  the  NG  Relay  Brick,  the  Camera  Node,  and  the  Illuminator  Node.  The  NG  Relay  Brick  was  designed  to 
improve  upon  the  earlier  Relay  Brick  developed  under  the  ADCR  system  by  using  a  higher-bandwidth  radio  with 
diversity  antenna  support.  System  tests  confirm  significant  improvement  in  link  reliability  and  reduction  in  roundtrip 
latency,  which  is  critical  in  urban  missions.  The  Camera  Node  was  designed  to  demonstrate  the  capability  of  the  mesh 
network  to  handle  an  additional  video  stream  along  with  the  existing  two  video  streams  transmitted  from  the  robotic 
platform,  as  well  as  the  ability  of  the  APDS  Deployer  to  handle  a  larger  payload  size.  The  Illuminator  node  is  yet 
another  payload  type  designed  to  illuminate  an  area  of  interest  for  remote  observation  via  NVGs.  The  BSU  designed 
under  the  APDS  project  provides  the  operator  the  capability  to  observe  the  status  of  the  system  when  the  robot  is  out  of 
sight,  and  to  command  the  release  of  payloads  (such  as  the  Camera  Node  and  the  Illuminator  Node)  at  desired  locations. 

Based  on  positive  feedback  received  from  NAVEODTECHDIV  regarding  the  performance  of  the  APDS  Deployer  and 
the  NG  Relay  Bricks  in  providing  NLOS  operational  capability  to  a  robotic  platform,  efforts  are  underway  to  further 
improve  the  radio  hardware  and  network  software  for  system  evaluation  by  the  users  in  theater.  Our  current  work 
consists  of  developing  a  modular  system  that  simplifies  payload  design  and  introduces  further  flexibility  by  allowing  the 
system  to  be  used  on  other  platforms,  manned  or  unmanned. 
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